Load testing for IP PBX systems

ABSTRACT

A method of load testing an IP PBX. The IP PBX is connected to a LAN, to which a registration simulator is also connected. The registration simulator is used to load the IP PBX with registrations. Actual phone calls are then made on the LAN, to determine whether the loading has adversely affected performance of the IP PBX. In this manner, the maximum CPU capacity of the IP PBX can be determined.

TECHNICAL FIELD OF THE INVENTION

[0001] This invention relates to IP (Internet Protocol) telephony, andmore particularly to testing IP PBX systems.

BACKGROUND OF THE INVENTION

[0002] PBX is short for private branch exchange, a private telephonenetwork used within an enterprise. Users of a PBX share a certain numberof outside lines for making telephone calls external to the PBX. Mostmedium-sized and larger companies use a PBX as a less expensivealternative to connecting an external telephone line to every telephonein the company. In addition, it's easier to call someone within a PBXbecause the number to dial is typically just 3 or 4 digits.

[0003] PBX architecture is undergoing an important transition fromcircuit-switched to packet-switched transmission and coding. The futureof voice communications, using PBX systems, seems to be headed towarduse of the Internet Protocol (IP).

[0004] While the design architectures of today's IP telephone systemsare diverse, the basic concept is that an IP telephone works like a PC.It has a LAN card with a MAC address and an IP address. It communicateswith an IP PBX via the IP protocol. Therefore, the IP PBX no longertracks phone numbers to physical devices. As a result, a phone can beeasily relocated to any functioning port without re-punching the line orchanging the PBX port setting. Essentially, you can move phones fromport to port like a PC, because the IP PBX no longer looks for the phonenumber at a physical location, it searches for the phone's IP addressacross the network. Phone numbers are encapsulated into an IP packet,transported across the network using the TCP/IP protocol and thende-encapsulated at the PBX.

[0005] VOIP (voice over Internet Protocol) is a technology devised toutilize existing IP infrastructures to carry voice. This can beaccomplished by using intelligent phones that have both a MAC address(NIC card) and an IP address. A speaker's voice is encapsulated into anIP packet and transmitted to the PBX. This allows the phone to beidentified by an IP address instead of a phone number. The reason behindthis is so that like a computer, a phone can be relocated easily to anylocation without the need for patching or PBX reprogramming.Essentially, since the PBX now communicates to the phone using IP, itwill know what phone number to send and receive voice informationregardless of location.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006]FIG. 1 illustrates an IP PBX load testing system in accordancewith the invention.

DETAILED DESCRIPTION OF THE INVENTION

[0007]FIG. 1 illustrates a load testing system 10 in accordance with theinvention. As explained below, system 10 provides a means for loadtesting the IP PBX 12. The load testing appropriately involves LANresources, telephone resources, and CPU resources within the IP PBX 12,and operates in conjunction with other test equipment that iscommercially available.

[0008] IP PBX 12 is the PBX being evaluated. As indicated in theBackground, a traditional PBX is a proprietary telephone-switchingsystem that resides within an enterprise network and connects internaltelephone extensions to each other and to the public switched telephonenetwork. Vendors program their PBX with applications'such as call hold,forwarding, and conference calling, and more complex call-centerapplications. Because traditional PBX technology is proprietary,customers usually have to ask their vendor to add new applications, andpay for the service. Similarly, traditional PBX vendors usuallyhandle—and charge for—adding, moving, and changing telephone extensions.Eliminating these expenses for users by using open protocols is abenefit of IP PBX technology. As the name implies, IP PBX 12 deliversPBX-like services, but over IP-based LANs or WANs rather thancircuit-switched networks. IP PBX systems can be designed as a singlenetwork server, a group of servers, or a network appliance. Despitewidespread use of open protocols, no real standards have been agreed onfor IP PBXs, so interoperability between IP systems, phones, and otherdevices, remains an issue.

[0009] In the example of this description, IP PBX 12 operates over a LAN14 and is designed as a single network server. However, as indicated inthe preceding paragraph, other configurations are possible and arecompatible with the invention described herein.

[0010] Phone sets 13 are compatible with IP PBX 12. Phone sets 13 are“intelligent” phone sets, i.e., computers, that communicate across a LAN14, using a predetermined protocol, which may vary depending on themanufacturer of IP PBX 12. Other types of endpoints may also beconnected to LAN 14, such as analog telephones or PCs with a telephoneapplication installed.

[0011] One task of phone sets 13 is to “register” with a call processor.Because the phone is assigned an IP address, the LAN automatically readsthe address. An IP number is analogous to a telephone number; ituniquely identifies a machine, but it does not identify a user.

[0012] Registration simulator 15 consists of software components thatcommunicate with IP PBX 12 using the protocols native to IP PBX 12. Asexplained below, simulator 15 eliminates the need to use actual phonesets for loading IP PBX 12, by performing simulated connections andregistrations with IP PBX 12. Simulator 15 need not make place orreceive actual phone calls.

[0013] Protocol analyzer 16 monitors activity on the LAN 14 and verifiesprotocols in use on the LAN 14. An example of a suitable protocolanalyzer 16 is the Internet Advisor, manufactured by AgilentCorporation.

[0014] Data traffic generator 17 loads LAN 14 with simulated data flows.An example of a suitable traffic generator 17 is the Smartbits trafficgenerator manufactured by Spirent Communications.

[0015] Gateway 18 permits IP PBX 12 to communicate with the publicswitched telephone network (PSTN) 19.

[0016] Voice traffic generator 20 generates voice traffic flows, thesame type of traffic as would be created by actual users. Voice trafficgenerator 20 may also include testing features, such as for connectiontesting and DTMF testing. Voice traffic generator 20 may also test andreport the quality of service for both voice and DTMF signals. Anexample of a suitable voice traffic generator 20 is the Hammer VOIP TestSystem, manufactured by Empirex.

[0017] Cell towers 21 represent communication links to cell phonesystems. This permits end to end quality of service testing for wirelessas well as wire line networks.

[0018] Phone set 22 represents one or more conventional phone sets thatmay be connected to PSTN 20.

[0019] In operation, simulator 17 registers a given number of simulatedtelephones with IP PBX 12. Each registration uses memory resources of IPPBX 12. The registration may include providing a unique Media AccessControl (MAC) address, a unique IP address, and the type of phone setbeing simulated. The number of telephone sets and MAC addresses that areregistered are tracked. It can then be determined whether the claimedcapacity of IP PBX, especially in terms of its memory resources, matchesthe number actually supported by IP PBX 12.

[0020] Data files containing MAC and IP addresses and telephone typesmay be developed and re-used. This permits different runs of simulator15 to produce consistent sets of results in terms of numbers oftelephone sets and MAC addresses that can be supported by IP PBX 12.

[0021] While IP PBX 12 is loaded with simulated registrations, phonesets 11 are used to make real telephone calls. Successful call placementindicates the IP PBX 12 has an actual loading capacity equivalent to thesimulated loading. Specifically, the CPU capability of IP PBX 12 may bedetermined by determining the maximum registrations that it may achievewhile still handling new calls.

[0022] Additional functions of simulator 15 include providing signalingto convince IP PBX 12 that simulator 15 is an authorized telephone settype. It may also be programmed to respond to “keep alive” pollingrequests from IP PBX 12. Simulator 15 may further be programmed tode-register with IP PBX 12 when simulator 15 ends execution.

[0023] For further testing system 10 while IP PBX 12 is loaded withsimulated registrations, LAN 14 may be loaded with data traffic. Forthis purpose, data and voice traffic may be generated using data trafficgenerator 17 and voice traffic generator 20. Gateway 18 is used inconventional manner so as to permit the LAN 14 and the voice network 19to communicate. At this point, IP PBX 12 can be examined to determinewhether it is properly handling the traffic.

[0024] During the network loading, protocol analyzer 16 may be used asan observation tool. It verifies that IP PBX is using the appropriateprotocols.

What is claimed is:
 1. A method of load testing an IP PBX, comprisingthe steps of: connecting a simulator process to the IP PBX; using thesimulator process to perform registrations with the IP PBX, theregistrations requesting at least a MAC address, an IP address, and atype of telephone; using the simulator process to provide signaling tothe IP PBX representing data representing authorization for a telephone;using the simulator process to respond to keep alive polling requestsfrom the IP PBX; and using the simulator process to de-register with theIP PBX.
 2. A method of load testing an IP PBX, comprising the steps of:connecting a simulator process to the IP PBX; and using the simulatorprocess to perform registrations with the IP PBX.
 3. The method of claim2, wherein the simulator process is performed by requesting at least aMAC address.
 4. The method of claim 2, wherein the simulator process isperformed by requesting at least an IP address.
 5. The method of claim2, wherein the simulator process is performed by providing datarepresenting a type of telephone.
 6. The method of claim 2, furthercomprising the step of using the simulator process to provide signalingto the IP PBX representing data representing authorization for atelephone.
 7. The method of claim 2, further comprising the step ofusing the simulator process to respond to keep alive polling requestsfrom the IP PBX.
 8. The method of claim 2, further comprising the stepof using the simulator process to de-register with the IP PBX.
 9. Themethod of claim 2, further comprising the steps of connecting the IP PBXand the simulator on a LAN and of generating data traffic on the LAN.10. The method of claim 2, wherein the IP PBX and the simulator areconnected on a LAN and further comprising the steps of using a gatewayto connect the LAN to a voice network and of generating voice traffic onthe voice network.